Remove foreach.nonIterable baseline and fix its issue - #13079
Conversation
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Test using WordPress PlaygroundThe changes in this pull request can previewed and tested using a WordPress Playground instance. WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser. Some things to be aware of
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
|
|
||
| // Remove registered custom meta capabilities. | ||
| foreach ( $this->cap as $cap ) { | ||
| foreach ( (array) $this->cap as $cap ) { |
There was a problem hiding this comment.
if $this->cap is a stdClass as the class property docblock claims, then will the (array) cast not create a clone of the data, iterate over the clone, delete properties from the clone, and then leave the original $this->cap untouched?
if so, wouldn’t that create a logical defect and nullify this code?
There was a problem hiding this comment.
Your comment would be valid i believe if we were actually unsetting properties of the actual $cap property. We don't though. So the only downside i see with this code is that its actually using a bit of extra memory because of the cloning.
There was a problem hiding this comment.
gotcha. thanks for pointing that out.
because I want to be careful here and make sure we are careful about changing code just because a linter flags a warning, I am checking this again.
in explicitly-casing to (array) we will still accept runtime corruption for things not castable into an array, but the PHPStan warning is silenced.
additionally, it seems like the change from iterating over an object’s properties to the array cast changes what’s iterated. whereas the existing foreach only iterates over public properties, the array cast is more equivalent to get_mangled_object_vars() and returns private and protected properties.
php > var_dump( $b, (array) $b, get_object_vars( $b ) );
object(Supervisor)#2 (4) {
["name":"Employee":private]=>
string(9) "sensitive"
["job"]=>
string(8) "recorder"
["tenure":protected]=>
int(0)
["name":"Supervisor":private]=>
string(9) "overruled"
}
array(4) {
["Employeename"]=>
string(9) "sensitive"
["job"]=>
string(8) "recorder"
["*tenure"]=>
int(0)
["Supervisorname"]=>
string(9) "overruled"
}
array(1) {
["job"]=>
string(8) "recorder"
}
php > foreach ( $b as $cap ) { var_dump( $cap ); }
string(8) "recorder"the cast to (array) silences the warning, but doesn’t really address the issue PHPStan raised, which is that we’re attempting to iterate over something that may not be iterable.
we could always throw in a check for is_iterable() around the foreach, which would address the reported warning, but I am also curious why PHPStan isn’t inferring that already?
$this->capis typed asstdClass(which is iterable)- it’s assigned from
get_post_type_capabilities()which is typed to return anobject
perhaps the problem is in PHPStan, or I’m still missing something.
02a241b to
e5ea710
Compare
e5ea710 to
f29015c
Compare
|
|
||
| // Remove registered custom meta capabilities. | ||
| foreach ( $this->cap as $cap ) { | ||
| foreach ( (array) $this->cap as $cap ) { |
There was a problem hiding this comment.
gotcha. thanks for pointing that out.
because I want to be careful here and make sure we are careful about changing code just because a linter flags a warning, I am checking this again.
in explicitly-casing to (array) we will still accept runtime corruption for things not castable into an array, but the PHPStan warning is silenced.
additionally, it seems like the change from iterating over an object’s properties to the array cast changes what’s iterated. whereas the existing foreach only iterates over public properties, the array cast is more equivalent to get_mangled_object_vars() and returns private and protected properties.
php > var_dump( $b, (array) $b, get_object_vars( $b ) );
object(Supervisor)#2 (4) {
["name":"Employee":private]=>
string(9) "sensitive"
["job"]=>
string(8) "recorder"
["tenure":protected]=>
int(0)
["name":"Supervisor":private]=>
string(9) "overruled"
}
array(4) {
["Employeename"]=>
string(9) "sensitive"
["job"]=>
string(8) "recorder"
["*tenure"]=>
int(0)
["Supervisorname"]=>
string(9) "overruled"
}
array(1) {
["job"]=>
string(8) "recorder"
}
php > foreach ( $b as $cap ) { var_dump( $cap ); }
string(8) "recorder"the cast to (array) silences the warning, but doesn’t really address the issue PHPStan raised, which is that we’re attempting to iterate over something that may not be iterable.
we could always throw in a check for is_iterable() around the foreach, which would address the reported warning, but I am also curious why PHPStan isn’t inferring that already?
$this->capis typed asstdClass(which is iterable)- it’s assigned from
get_post_type_capabilities()which is typed to return anobject
perhaps the problem is in PHPStan, or I’m still missing something.
2 participants
Removes in total
1errors.Removes errors from the below phpstan baselines and fixes the issues that they were covering:
How ?
By type casting the property to array.
Trac ticket: https://core.trac.wordpress.org/ticket/65817
Use of AI Tools
AI assistance: Yes
Tool(s): Claude Code
Model(s): Opus 5
Used for: Help with suggesting how to fix the phpstan output for the specific errors we are removing the baselines for. The actual result has been reviewed and are owned by me.
This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.